Before returning, aaaaffffRRRReeeeaaaaddddFFFFrrrraaaammmmeeeessss(((()))) automatically updates the read pointer
for _t_r_a_c_k so that it points to the sample frame following the last one
copied into _s_a_m_p_l_e_s.
Note that the data type of the samples in this buffer can vary depending
on the sample format and sample width of the samples in the _t_r_a_c_k. The
_s_a_m_p_l_e_s buffer is interpreted differently depending on the current
configuration of the audio track. The _s_a_m_p_w_i_d_t_h parameter returned by
aaaaffffGGGGeeeettttSSSSaaaammmmpppplllleeeeFFFFoooorrrrmmmmaaaatttt(3dm) may or may not be meaningful, depending on the
value of _s_a_m_p_f_m_t. See aaaaffffGGGGeeeettttSSSSaaaammmmpppplllleeeeFFFFoooorrrrmmmmaaaatttt(3dm) for a full explanation of
sample representations.
aaaaffffRRRReeeeaaaaddddFFFFrrrraaaammmmeeeessss(((()))) automatically decompresses data which was encoded with the
CCITT G.722, CCITT G.711, MPEG, and Aware compression. By default, the
data for all currently supported compression formats is presented to
application programs in the standard two's complement linear PCM format,
but this is by no means guaranteed for future compression types. See
aaaaffffGGGGeeeettttCCCCoooommmmpppprrrreeeessssssssiiiioooonnnn(3dm) and aaaaffffSSSSeeeettttVVVViiiirrrrttttuuuuaaaallllSSSSaaaammmmpppplllleeeeFFFFoooorrrrmmmmaaaatttt for further
information. To achieve real-time G.722 compression, the application
process may require non-degrading scheduling priority (see sssscccchhhheeeeddddccccttttllll(2) or
nnnnpppprrrriiii(1))
If an audio track contains data for more than a single audio channel, the
data returned in the _s_a_m_p_l_e_s buffer will be interleaved. For stereo
data, the samples are always grouped in left/right pairs (sample frames).
For reference, interleave conventions for files containing multichannel